1. Field of the Invention
The present invention relates to networked data processing environments using a client/server architecture, and, in particular, to client-server systems where there exist one or more clients of varying capability connected via network connections of varying bandwidth and latentcy to one or more servers providing application services or database services to the connected clients.
2. Background Information
Until the 1980s the computer network typically was used as a means of connecting to a large mainframe environment using dedicated hardware terminals and proprietary protocols. Next UNIX servers grew in usage and with it came standardization of the networking protocols, in particular TCP/IP (Transmission Control Protocol/Internet Protocol). Simultaneously, there was a shift in the computing paradigm towards client/server architectures. This allowed the processing power to be distributed over the network and not be limited to servers which could not scale to meet the growing number of users and their increasing demands. This lead to the need for clients to become more intelligent and powerful. Significant desktop clients came into use: Microsoft Windows. Each iteration of this operating system brought about more functionality requiring more powerful desktop clients. More and more software had to be installed on these clients leading to what is termed "fat clients" and each client required individual configuration. People began to find that the amount of time and money required to maintain these powerful clients was increasing.
High availability networks together with hardware and software needed to support such networks have become the norm. In these environments there is not a homogeneous structure of one type of server and one type of client, but a variety of such devices. Within a network there is a wide variety or servers and clients. Upgrades and new applications for this diverse mix of clients usually requires that each client be individually upgraded. Also each user has specific needs on the desktop client: configuration, security, access control, mobility. The information services department provides this by administering each client separately. If remote offices are involved, costs to do this increase significantly. Performance in this heterogeneous client network must also be maintained. Slow performance takes up time and money. Networks vary in bandwidth, e.g. modem links, ATMs, Frame Relays, etc.
The World Wide Web (the "Web") has come to the forefront in the current era of the Internet/intranet and networks have become an integral part of day to day work. Modem speeds double every year and 100 Mbit/sec Local Area Networks have arrived. The Web is now a well-accepted medium for publishing information, in the form of text and graphics (including sound and video). Web programming languages such as Java, JavaScript, and CGI have now extended the Web to applications. This is fine for new applications but existing applications also need a route into this world.
Existing applications have either had a character-based or windows-based user interface. Now such applications need a web user interface. The web user interface provides a presentation layer to the user of the application. It must provide an input/output method for the user to interact with the application. There are a number of ways to do this including: (1) HTML (HyperText Markup Language) replacement of the current user interface; (2) Non-Java plug-ins; and (3) Java-based emulation. The first solution involves rewriting the application. The second involves installing more software on the clients leading to "fat clients". The third is preferred.
A large number of vendors offer a character or graphical emulation package that runs on desktop clients such as Windows, UNIX, etc. These emulators could be rewritten in Java and such Java emulator will run on just about any client. However, this approach leads to fat Java clients. For performance reasons, users will not want to wait for large Java applets to download. These Java applets will grow in size as users demand more and more functionality. Storing these Java applets locally solves the performance problem but leads to fat clients. If state information is stored on the client leading each client to have its own particular configuration parameters, the problem of fat clients is further exacerbated and each client is being managed individually rather than from a central place on the server.
Web browsers have an API (Application Programmers Interface) enabling software developers to provide helper applications that allow users to run applications or view unsupported document types on their client platform. These are termed "browser plug-ins". They are both platform-specific and browser-specific. For example, for two platforms (Windows and UNIX) and two browser types (Netscape and Microsoft), four different implementations of the plug-in would be needed. This type of solution is not cross platform and the majority of these plug-ins are proprietary (e.g., Microsoft ActiveX) locking users into vendor specific solutions.
Once the web display of an application is possible, the next step is to make it available to all users. A number of methods that could be used include: (1) local installation; (2) push technology; (3) on-demand access. Local installation involves an administrator installing the application or connectivity software on every single client. This is disadvantageous in that it makes the clients more difficult and costly to manage and leads to fat clients. Push technology involves storing all the files and data associated with users and applications on a server and transmitting them out via virtual channels on a network to clients. Where all storage is on the sever, users experience poor performance in waiting for applets and applications to execute, or downloads are cumbersome and in some cases unusable. Local storage of applications and state information is used to improve performance. This approach starts off well by using a central server but when applications and any associated state are stored on the client, the fat client problem arises. With on-demand access as used in the present invention, user state, applications, connectivity software and the associated configuration data are stored on a server. Applets are downloaded on demand when the clients request an action, such as start up an application. All state information is kept on the server and can then be managed centrally rather than individually on each client. Keeping state information on the server also makes the client resilient. If the client connection is lost or the client itself is replaced, nothing is lost and no replication is needed.
Next the applications and data must be made available to selected users in a secure manner. For manageability, this is done centrally on a server and made available by the most common medium to all users, the Web. But this raises more questions:
What do web pages on that server have to contain? PA1 What editor has to be used? PA1 How do you make it available to selected users or groups of users? PA1 Are there different web pages for different types of users? PA1 Where does the user profile and application configuration reside? PA1 Do users authenticate themselves every time they want to run applications? PA1 How is the authentication done? PA1 What if the user is already authenticated on the server and does not want to do again and again for each application? PA1 What if all of this information is already available and duplication is not desired? PA1 deleting from the second queue the display request whose first sequence identifier is the same as the second sequence identifier and all pending displayed requests in the second queue having first sequence identifiers that are prior to such second sequence identifier; and PA1 decrementing from the total request time and from the total network time the request time values of each of the deleted display requests.
As the above list shows, providing a display mechanism via Java emulation is only a partial solution to web-based delivery of applications.
To achieve optimal performance on all networks is difficult. Protocols are designed with specific functions in mind, e.g., inter-process communication, graphics rendering, etc. Protocols are rarely designed with the goal of providing uniform performance over complex network routes that have different permutations of bandwidths. To choose the right protocol a number of assumptions could be made. For a high bandwidth network, such as a fast LAN with low latency, the X protocol works well but is unusable over a slow modem link. For a low bandwidth network, such as a slow WAN or modem connection, compression can be used to optimize performance. The ICA protocol of Citrix Systems, Inc. works well over a slow modem connection but is inefficient on a fast LAN connection.
It would be advantageous to be able to deliver upgrades to existing applications or roll out new applications to diverse clients; to be able to centralize the administration of clients and their applications; to have a system that is able to adapt itself to the network environment it works in; and to provide optimal performance for diverse clients that are connected to the network via routing connections of differing bandwidth and performance.